SherbyNet - /page/wikibook/entry.mu

Micron Document

<!DOCTYPE html>

<title>Test driven development</title>

</head>

<h1 id="firstHeading" class="firstHeading mw-first-heading"><span class="mw-page-title-main">Test driven development</span></h1>

</header>

</div>

<div id="mw-content-text" class="mw-body-content mw-content-ltr" lang="fr" dir="ltr"><div class="mw-content-ltr mw-parser-output" lang="fr" dir="ltr"><p><i><b><span class="lang-en" lang="en">Test-Driven Development</span></b></i> (<b>TDD</b>), ou le <b>développement piloté par les tests</b> en français<sup id="cite_ref-1" class="reference"><a href="#cite_note-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup><sup class="reference cite_virgule">,</sup><sup id="cite_ref-2" class="reference"><a href="#cite_note-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup><sup class="reference cite_virgule">,</sup><sup id="cite_ref-3" class="reference"><a href="#cite_note-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup><sup class="reference cite_virgule">,</sup><sup id="cite_ref-4" class="reference"><a href="#cite_note-4"><span class="cite-bracket">[</span>4<span class="cite-bracket">]</span></a></sup>, est une méthode de <a href="D%C3%A9veloppement_de_logiciel" title="Développement de logiciel">développement de logiciel</a> qui consiste à concevoir un <a href="Logiciel" title="Logiciel">logiciel</a> par des itérations successives très courtes (ou petits pas), telles que chaque <a href="It%C3%A9ration" title="Itération">itération</a> est accomplie en formulant un sous-problème à résoudre sous forme d'un test avant d'écrire le <a href="Code_source" title="Code source">code source</a> correspondant, et où le code est continuellement remanié dans une volonté de simplification.

</p>

<div class="mw-heading mw-heading2"><h2 id="Origine">Origine</h2></div>

<p>L'ingénieur logiciel <a href="Kent_Beck" title="Kent Beck">Kent Beck</a> est crédité pour avoir découvert ou redécouvert la méthode. A propos de cette decouverte il a déclaré en 2013 sur le forum Quora<sup id="cite_ref-5" class="reference"><a href="#cite_note-5"><span class="cite-bracket">[</span>5<span class="cite-bracket">]</span></a></sup>  :

</p>

<p>« The original description of TDD was in an ancient book about programming. It said you take the input tape, manually type in the output tape you expect, then program until the actual output tape matches the expected output. After I'd written the first xUnit framework in <a href="Smalltalk" title="Smalltalk">Smalltalk</a> I remembered reading this and tried it out. That was the origin of TDD for me. When describing TDD to older programmers, I often hear, "Of course. How else could you program?" Therefore I refer to my role as "rediscovering" TDD. »

</p>

</blockquote><p style="margin:-0.7em 0 0.3em 6em">— <a href="Kent_Beck" title="Kent Beck">Kent Beck</a>, <cite>Why does Kent Beck refer to the "rediscovery" of test-driven development? What's the history of test-driven development before Kent Beck's rediscovery?

</cite></p>

<div class="mw-heading mw-heading2"><h2 id="Cycles_de_TDD">Cycles de TDD</h2></div>

<div class="mw-heading mw-heading3"><h3 id="Les_trois_lois_de_TDD">Les trois lois de TDD</h3></div>

<p>À l'origine, il s'agissait simplement d'écrire les tests avant de coder, et cette méthode s'appelait le <i>Test-First Design</i><sup id="cite_ref-:1_6-0" class="reference"><a href="#cite_note-:1-6"><span class="cite-bracket">[</span>6<span class="cite-bracket">]</span></a></sup>. Puis elle évolua vers une granularité de développement plus fine : pour une ligne de test en échec, une <a href="Ligne_de_code" title="Ligne de code">ligne de code</a> de production est écrite, afin que le test réussisse. Afin d'entériner cette granularité de ligne à ligne entre code de test et code de production, trois lois ont émergé.

</p>

<caption>Formulation en 2008 des lois de TDD

</caption>

<th>Dénomination

</th>

<th>Traduction française

</th>

<th>Version originale

</th>

<th>Note d'interprétation

</th></tr>

<tr>

<td>Loi <abbr class="abbr" title="numéro">n<sup>o</sup></abbr> 1

</td>

<td>Vous ne pouvez pas écrire de code de production tant que vous n'avez pas écrit un test unitaire qui échoue.

</td>

<td><span class="lang-en" lang="en">"You may not write production code until you have written a failing unit test."</span><sup id="cite_ref-:0_7-0" class="reference"><a href="#cite_note-:0-7"><span class="cite-bracket">[</span>7<span class="cite-bracket">]</span></a></sup>

</td>

<td>C'est-à-dire qu'il n'est permis d'écrire du code de production que si un test unitaire est en échec<sup id="cite_ref-rcmartin_blog_8-0" class="reference"><a href="#cite_note-rcmartin_blog-8"><span class="cite-bracket">[</span>8<span class="cite-bracket">]</span></a></sup>.

</td></tr>

<tr>

<td>Loi <abbr class="abbr" title="numéro">n<sup>o</sup></abbr> 2

</td>

<td>Vous ne pouvez pas écrire plus de code de test qu'il n'en faut pour qu'un test unitaire échoue, et ne pas compiler revient à échouer.

</td>

<td><span class="lang-en" lang="en">"You may not write more of a unit test than is sufficient to fail, and not compiling is failing."</span><sup id="cite_ref-:0_7-1" class="reference"><a href="#cite_note-:0-7"><span class="cite-bracket">[</span>7<span class="cite-bracket">]</span></a></sup>

</td>

<td>C'est-à-dire qu'il n'est permis d'écrire qu'un nouveau test unitaire en échec à la fois, et un test unitaire qui ne compile pas est déjà un test en échec<sup id="cite_ref-rcmartin_blog_8-1" class="reference"><a href="#cite_note-rcmartin_blog-8"><span class="cite-bracket">[</span>8<span class="cite-bracket">]</span></a></sup>.

</td></tr>

<tr>

<td>Loi <abbr class="abbr" title="numéro">n<sup>o</sup></abbr> 3

</td>

<td>Vous ne pouvez pas écrire plus de code de production que nécessaire pour que le test unitaire actuellement en échec réussisse.

</td>

<td><span class="lang-en" lang="en">"You may not write more production code than is sufficient to pass the currently failing test."</span><sup id="cite_ref-:0_7-2" class="reference"><a href="#cite_note-:0-7"><span class="cite-bracket">[</span>7<span class="cite-bracket">]</span></a></sup>

</td>

<td>C'est-à-dire qu'il n'est permis d'écrire que du code de production permettant directement de faire passer le test unitaire précédent, ni plus ni moins<sup id="cite_ref-rcmartin_blog_8-2" class="reference"><a href="#cite_note-rcmartin_blog-8"><span class="cite-bracket">[</span>8<span class="cite-bracket">]</span></a></sup>.

</td></tr></tbody></table>

<p>Ces lois connaissent différentes variantes très similaires entre 2005 et 2008 (2005<sup id="cite_ref-rcmartin_blog_8-3" class="reference"><a href="#cite_note-rcmartin_blog-8"><span class="cite-bracket">[</span>8<span class="cite-bracket">]</span></a></sup>, 2006<sup id="cite_ref-9" class="reference"><a href="#cite_note-9"><span class="cite-bracket">[</span>9<span class="cite-bracket">]</span></a></sup>, 2007<sup id="cite_ref-article_ieee_2007_10-0" class="reference"><a href="#cite_note-article_ieee_2007-10"><span class="cite-bracket">[</span>10<span class="cite-bracket">]</span></a></sup> et 2008<sup id="cite_ref-:0_7-3" class="reference"><a href="#cite_note-:0-7"><span class="cite-bracket">[</span>7<span class="cite-bracket">]</span></a></sup>), toujours écrites par <a href="Robert_C._Martin" title="Robert C. Martin">Robert C. Martin</a> : elles sont ici énoncées selon les termes utilisés en 2008<sup id="cite_ref-:0_7-4" class="reference"><a href="#cite_note-:0-7"><span class="cite-bracket">[</span>7<span class="cite-bracket">]</span></a></sup>. Or l'emploi de l'expression "<a href="Test_unitaire" title="Test unitaire">test unitaire</a>" dans ces lois prête ici largement à confusion. Par test unitaire, ces lois ne désignent pas un cas de test complet, mais en fait une unique assertion de test. Le cas de test complet devrait être obtenu après avoir répété plusieurs fois les étapes correspondant à ces trois lois, sachant que la résolution d'une erreur de compilation constitue déjà une itération à part entière. En 2014, Robert C. Martin reformule d'ailleurs les lois de TDD<sup id="cite_ref-:1_6-1" class="reference"><a href="#cite_note-:1-6"><span class="cite-bracket">[</span>6<span class="cite-bracket">]</span></a></sup>, et le terme « unitaire » disparaît.

</p><p>Une formulation exacte et exempte de toute ambiguïté de ces 3 lois serait plutôt comme suit. La forme est volontairement affirmative ici, car l'esprit humain comprend plus aisément ce qu'il faut faire que ce qu'il ne faut pas faire.

</p>

<caption>Sans le terme "unitaire" et sans ambiguïté

</caption>

<th>Dénomination

</th>

<th>Reformulation<sup id="cite_ref-11" class="reference"><a href="#cite_note-11"><span class="cite-bracket">[</span>11<span class="cite-bracket">]</span></a></sup>

</th></tr>

<tr>

<td>Loi <abbr class="abbr" title="numéro">n<sup>o</sup></abbr> 1

</td>

<td>Écrivez un test qui échoue avant d’écrire le code de production correspondant.

</td></tr>

<tr>

<td>Loi <abbr class="abbr" title="numéro">n<sup>o</sup></abbr> 2

</td>

<td>Écrivez une seule assertion à la fois, qui fait échouer le test ou qui échoue à la compilation.

</td></tr>

<tr>

<td>Loi <abbr class="abbr" title="numéro">n<sup>o</sup></abbr> 3

</td>

<td>Écrivez le minimum de code de production pour que l'assertion du test actuellement en échec soit satisfaite.

</td></tr></tbody></table>

<p>On fait ainsi la distinction entre l'assertion à l'origine de l'échec du test et le test qui échoue lors de son exécution. De plus, on ne présume pas de la forme de test la plus adéquate, ni ne se restreint à une seule possible, ce qui est d'autant plus pragmatique. Le fait de mettre bout à bout les trois lois de TDD en une seule itération constitue ce qui est appelé un nano-cycle de TDD. À noter que ces trois lois ne couvrent que les conditions à respecter en TDD pour arriver à un test qui réussit, en exprimant le minimalisme attendu du test en échec.

</p>

<div class="mw-heading mw-heading3"><h3 id="Processus_cyclique_de_développement"><span id="Processus_cyclique_de_d.C3.A9veloppement"></span>Processus cyclique de développement</h3></div>

<p>Le processus préconisé par TDD comporte cinq étapes<sup id="cite_ref-12" class="reference"><a href="#cite_note-12"><span class="cite-bracket">[</span>12<span class="cite-bracket">]</span></a></sup> :

</p>

<ol><li>écrire un seul test qui décrit une partie du problème à résoudre ;</li>

<li>vérifier que le test échoue, autrement dit qu'il est valide, c'est-à-dire que le code se rapportant à ce test n'existe pas ;</li>

<li>écrire juste assez de code pour que le test réussisse ;</li>

<li>vérifier que le test passe, ainsi que les autres tests existants ;</li>

<li><a href="R%C3%A9usinage_de_code" title="Réusinage de code">remanier</a> le code, c'est-à-dire l'améliorer sans en altérer le comportement, qu'il s'agisse du code de production ou du code de test.</li></ol>

<p>Ce processus est répété en plusieurs cycles, jusqu'à résoudre le problème d'origine dans son intégralité. Ces cycles itératifs de développement sont appelés les micro-cycles de TDD.

</p>

<div class="mw-heading mw-heading2"><h2 id="Intérêt"><span id="Int.C3.A9r.C3.AAt"></span>Intérêt</h2></div>

<div class="mw-heading mw-heading3"><h3 id="Vérification_et_validation"><span id="V.C3.A9rification_et_validation"></span>Vérification et validation</h3></div>

<p>Les tests tels qu'ils sont mis à profit en TDD permettent d'explorer et de préciser le besoin, puis de spécifier le comportement souhaité du logiciel en fonction de son utilisation, avant chaque étape de codage. Le logiciel ainsi produit est tout à la fois pensé pour répondre avec justesse au besoin et conçu pour le faire avec une <a href="Complexit%C3%A9_essentielle" title="Complexité essentielle">complexité minimale</a>. On obtient donc un logiciel mieux conçu, mieux testé et plus fiable, autrement dit de meilleure qualité.

</p><p>Quand les tests sont écrits après codage, <span class="need_ref" title="Ce passage nécessite une explication." style="cursor:help;">comme c'est le cas traditionnellement</span><sup class="need_ref_tag" style="padding-left:2px;">[En quoi ?]</sup>, les choix d'implémentation contraignent l'écriture des tests : les tests sont écrits en fonction du code, et si certaines parties du code ne sont pas testables, elles ne seront pas testées. Au contraire, en testant avant de coder, on utilise le code avant son implémentation, de sorte que les contraintes définies par les tests s’imposent à l'implémentation : le code est écrit en fonction des tests. Le fait d'écrire les tests avant le code en TDD conduit donc à des implémentations testables, c'est-à-dire faciles à tester et entièrement testables. Or la <a href="Testabilit%C3%A9" title="Testabilité">testabilité</a> du code favorise une meilleure conception par un couplage lâche et une cohésion forte, ce qui évite des erreurs de conception courantes.

</p>

<div class="mw-heading mw-heading3"><h3 id="Non-régression"><span id="Non-r.C3.A9gression"></span>Non-régression</h3></div>

<p>Comme chaque test correspond à un changement minimal de code, un test unique permet de faire un lien évident entre une régression et sa cause s'il échoue. Ce lien fait de l'exécution des tests un moment charnière dans un cycle de TDD : on capture l'état instantané du logiciel et on détecte d'éventuelles régressions à la suite du dernier changement. En effet, on veut <span class="need_ref" title="Une source est souhaitée pour ce passage." style="cursor:help;">à tout prix</span><sup class="need_ref_tag" style="padding-left:2px;">[<abbr class="abbr" title="référence">réf.</abbr> souhaitée]</sup> éviter de modifier le code en présence d'une régression. Dans le cas contraire, on ne saurait dire avec certitude si les tests échouent à cause du dernier changement ou d'un changement antérieur. C'est en cela que les tests déjà écrits constituent un filet de sécurité contre des accidents de parcours où l'on perdrait le lien entre changement et régression. Ce filet de sécurité permet d'envisager avec sérénité n'importe quelle modification du code, qu'il s'agisse d'une transformation (modification qui affecte le comportement) ou d'un <a href="R%C3%A9usinage_de_code" title="Réusinage de code">remaniement</a> (modification qui ne devrait pas altérer le comportement). Ainsi les nouvelles livraisons des nouvelles versions du logiciel ne devraient pas contenir de régression.

</p><p>L'enjeu du remaniement continu du code est de réaligner la conception du code avec les besoins connus, afin de lutter contre l'<a href="D%C3%A9gradation_logicielle" title="Dégradation logicielle">entropie logicielle</a> et de prévenir la <a href="Dette_technique" title="Dette technique">dette technique</a>. Changer la conception du code sans en altérer le comportement requiert de disposer de suffisamment de tests pour garantir l'absence de régression. Pour cela, un développeur devrait faire appel à différentes formes complémentaires de test, de manière à ne pas les réécrire à chaque remaniement de code, quelle que soit l'étendue des remaniements : <span class="need_ref" title="Ce passage devrait préciser au minimum la décennie ou l'année." style="cursor:help;">tantôt</span><sup class="need_ref_tag" style="padding-left:2px;">[Quand ?]</sup> des tests pour vérifier les résultats exacts d'un traitement, <span class="need_ref" title="Ce passage devrait préciser au minimum la décennie ou l'année." style="cursor:help;">tantôt</span><sup class="need_ref_tag" style="padding-left:2px;">[Quand ?]</sup> des tests pour vérifier que des composants collaborent correctement, sans que ces différents tests échouent ensemble pour les mêmes raisons<sup id="cite_ref-13" class="reference"><a href="#cite_note-13"><span class="cite-bracket">[</span>13<span class="cite-bracket">]</span></a></sup>.

</p>

<div class="mw-heading mw-heading3"><h3 id="Gains_recherchés"><span id="Gains_recherch.C3.A9s"></span>Gains recherchés</h3></div>

<p>Comme les tests sont écrits avant le code, ils trouvent plusieurs utilités en TDD : ils servent d'abord à résoudre — c'est-à-dire à poser — un problème en guidant le codage à chaque étape, ils fournissent ensuite un filet de sécurité contre les <a href="Test_de_r%C3%A9gression" title="Test de régression">régressions</a> et, enfin, ils contribuent à documenter le comportement du logiciel. Grâce à son utilisation des tests, TDD fait gagner en productivité de plusieurs façons.

</p>

<ul><li>TDD permet d'éviter des modifications de code sans lien avec le but recherché, car on se focalise à chaque cycle sur la satisfaction d'un besoin précis, en conservant le cap du problème d'ensemble à résoudre.</li>

<li>TDD permet d'éviter les accidents de parcours, où des tests échouent sans qu'on puisse identifier le changement responsable, ce qui aurait pour effet d'allonger la durée d'un cycle de développement.</li>

<li>TDD permet de maîtriser le coût des évolutions logicielles au fil du temps, grâce à une conception du code perméable au changement.</li>

<li>TDD permet de s'approprier plus facilement n'importe quelle partie du code en vue de le faire évoluer, car chaque test ajouté dans la construction du logiciel explique et documente le comportement du logiciel en distillant l'intention des auteurs.</li>

<li>TDD permet de livrer une nouvelle <a href="Version_d'un_logiciel" title="Version d'un logiciel">version d'un logiciel</a> avec un haut niveau de confiance dans la qualité des livrables, confiance justifiée par la couverture et la pertinence des tests à sa construction<sup id="cite_ref-14" class="reference"><a href="#cite_note-14"><span class="cite-bracket">[</span>14<span class="cite-bracket">]</span></a></sup>.</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Programmation_en_binôme"><span id="Programmation_en_bin.C3.B4me"></span>Programmation en binôme</h2></div>

<p>Lorsque deux personnes s'associent en <a href="Extreme_programming#Programmation_en_binôme" title="Extreme programming">binôme</a> pour résoudre un problème de programmation, elles occupent tour à tour deux rôles semblables à ceux d'un <a href="Rallye_automobile#Les_équipages" title="Rallye automobile">équipage</a> de <a href="Rallye_automobile" title="Rallye automobile">rallye automobile</a> : le pilote, qui tient le clavier, code, tandis que le copilote supervise, prend du recul et guide son pilote par étapes, puis les rôles sont échangés à intervalles réguliers. En appliquant TDD, un binôme peut échanger les rôles de différentes façons : soit entre deux cycles de développement au moment d'itérer, soit entre l'écriture d'un nouveau test en échec et le codage d'un nouveau comportement. La seconde façon d'échanger les rôles force à séparer les préoccupations du test de celles de l'implémentation et met le copilote à contribution pour écrire le test seulement, tandis que la première permet de dérouler un cycle complet en occupant un même rôle<sup id="cite_ref-15" class="reference"><a href="#cite_note-15"><span class="cite-bracket">[</span>15<span class="cite-bracket">]</span></a></sup>.

</p>

<div class="mw-heading mw-heading2"><h2 id="Notes_et_références"><span id="Notes_et_r.C3.A9f.C3.A9rences"></span>Notes et références</h2></div>

<li id="cite_note-1"><span class="mw-cite-backlink"><a href="#cite_ref-1">↑</a> </span><span class="reference-text"><span class="ouvrage" id="Pradat-PeyrePrintz2021"><span class="ouvrage" id="Jean-François_Pradat-PeyreJacques_Printz2021">Jean-François <span class="nom_auteur">Pradat-Peyre</span> et Jacques <span class="nom_auteur">Printz</span>, <cite class="italique">Pratique des tests logiciels - 4e éd.: Améliorer la qualité par les tests. Préparer la certification ISTQB</cite>, Dunod, <time class="nowrap" datetime="2021-02-03" data-sort-value="2021-02-03">3 février 2021</time> <small style="line-height:1em;">(<a href="International_Standard_Book_Number" title="International Standard Book Number">ISBN</a> <span class="nowrap">978-2-10-082250-8</span>, <a rel="nofollow" class="external text" href="https://www.google.fr/books/edition/Pratique_des_tests_logiciels_4e_%C3%A9d/-1QXEAAAQBAJ?hl=pl&gbpv=1&dq=%22d%C3%A9veloppement+pilot%C3%A9+par+les+tests%22&pg=PT34&printsec=frontcover">lire en ligne</a>)</small><span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Pratique+des+tests+logiciels+-+4e+%C3%A9d.%3A+Am%C3%A9liorer+la+qualit%C3%A9+par+les+tests.+Pr%C3%A9parer+la+certification+ISTQB&rft.pub=Dunod&rft.aulast=Pradat-Peyre&rft.aufirst=Jean-Fran%C3%A7ois&rft.au=Printz%2C+Jacques&rft.date=2021-02-03&rft.isbn=978-2-10-082250-8&rfr_id=info%3Asid%2Ffr.wikipedia.org%3ATest+driven+development"></span></span></span></span>

</li>

<li id="cite_note-2"><span class="mw-cite-backlink"><a href="#cite_ref-2">↑</a> </span><span class="reference-text"><span class="ouvrage" id="Singh2021"><span class="ouvrage" id="Ajit_Singh2021">Ajit <span class="nom_auteur">Singh</span>, <cite class="italique">Agile & Scrum: Un aperçu</cite>, Babelcube Inc., <time class="nowrap" datetime="2021-01-01" data-sort-value="2021-01-01"><abbr class="abbr" title="premier">1<sup>er</sup></abbr> janvier 2021</time> <small style="line-height:1em;">(<a href="International_Standard_Book_Number" title="International Standard Book Number">ISBN</a> <span class="nowrap">978-1-0715-8253-4</span>, <a rel="nofollow" class="external text" href="https://www.google.fr/books/edition/Agile_Scrum/AOsWEAAAQBAJ?hl=pl&gbpv=1&dq=%22d%C3%A9veloppement+pilot%C3%A9+par+les+tests%22&pg=PT27&printsec=frontcover">lire en ligne</a>)</small><span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Agile+%26+Scrum%3A+Un+aper%C3%A7u&rft.pub=Babelcube+Inc.&rft.aulast=Singh&rft.aufirst=Ajit&rft.date=2021-01-01&rft.isbn=978-1-0715-8253-4&rfr_id=info%3Asid%2Ffr.wikipedia.org%3ATest+driven+development"></span></span></span></span>

</li>

<li id="cite_note-3"><span class="mw-cite-backlink"><a href="#cite_ref-3">↑</a> </span><span class="reference-text"><span class="ouvrage" id="Aubry2013"><span class="ouvrage" id="Claude_Aubry2013">Claude <span class="nom_auteur">Aubry</span>, <cite class="italique">Scrum - 3e éd.: Le guide pratique de la méthode agile la plus populaire</cite>, Dunod, <time class="nowrap" datetime="2013-06-19" data-sort-value="2013-06-19">19 juin 2013</time> <small style="line-height:1em;">(<a href="International_Standard_Book_Number" title="International Standard Book Number">ISBN</a> <span class="nowrap">978-2-10-059448-1</span>, <a rel="nofollow" class="external text" href="https://www.google.fr/books/edition/Scrum_3e_%C3%A9d/cFaKSe6uQa4C?hl=pl&gbpv=1&dq=%22d%C3%A9veloppement+pilot%C3%A9+par+les+tests%22&pg=PT255&printsec=frontcover">lire en ligne</a>)</small><span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Scrum+-+3e+%C3%A9d.%3A+Le+guide+pratique+de+la+m%C3%A9thode+agile+la+plus+populaire&rft.pub=Dunod&rft.aulast=Aubry&rft.aufirst=Claude&rft.date=2013-06-19&rft.isbn=978-2-10-059448-1&rfr_id=info%3Asid%2Ffr.wikipedia.org%3ATest+driven+development"></span></span></span></span>

</li>

<li id="cite_note-4"><span class="mw-cite-backlink"><a href="#cite_ref-4">↑</a> </span><span class="reference-text"><span class="ouvrage" id="PauliPonçon2011"><span class="ouvrage" id="Julien_PauliGuillaume_Ponçon2011">Julien <span class="nom_auteur">Pauli</span> et Guillaume <span class="nom_auteur">Ponçon</span>, <cite class="italique">Zend Framework: Bien développer en PHP</cite>, Editions Eyrolles, <time class="nowrap" datetime="2011-07-07" data-sort-value="2011-07-07">7 juillet 2011</time> <small style="line-height:1em;">(<a href="International_Standard_Book_Number" title="International Standard Book Number">ISBN</a> <span class="nowrap">978-2-212-14717-9</span>, <a rel="nofollow" class="external text" href="https://www.google.fr/books/edition/Zend_Framework/_pUP4lLemqIC?hl=pl&gbpv=1&dq=%22d%C3%A9veloppement+pilot%C3%A9+par+les+tests%22&pg=PR17&printsec=frontcover">lire en ligne</a>)</small><span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Zend+Framework%3A+Bien+d%C3%A9velopper+en+PHP&rft.pub=Editions+Eyrolles&rft.aulast=Pauli&rft.aufirst=Julien&rft.au=Pon%C3%A7on%2C+Guillaume&rft.date=2011-07-07&rft.isbn=978-2-212-14717-9&rfr_id=info%3Asid%2Ffr.wikipedia.org%3ATest+driven+development"></span></span></span></span>

</li>

<li id="cite_note-5"><span class="mw-cite-backlink"><a href="#cite_ref-5">↑</a> </span><span class="reference-text"><span class="ouvrage" id="Beck2013"><span class="ouvrage" id="Kent_Beck2013"><abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> Kent Beck, « <a rel="nofollow" class="external text" href="https://www.quora.com/Why-does-Kent-Beck-refer-to-the-rediscovery-of-test-driven-development-Whats-the-history-of-test-driven-development-before-Kent-Becks-rediscovery/answer/Kent-Beck"><cite style="font-style:normal;" lang="en">Why does Kent Beck refer to the "rediscovery" of test-driven development? What's the history of test-driven development before Kent Beck's rediscovery?</cite></a> » <span class="skin-invert-image" typeof="mw:File"><span title="Accès libre au document"></span></span>, sur <span class="italique">Quora</span>, <time>2013</time> <small style="line-height:1em;">(consulté le <time class="nowrap" datetime="2025-02-24" data-sort-value="2025-02-24">24 février 2025</time>)</small></span></span></span>

</li>

<li id="cite_note-:1-6"><span class="reference-text"><span class="ouvrage" id="Martin"><span class="ouvrage" id="Robert_C._Martin"><abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> Robert C. Martin, « <a rel="nofollow" class="external text" href="http://blog.cleancoder.com/uncle-bob/2014/12/17/TheCyclesOfTDD.html"><cite style="font-style:normal;" lang="en">The Cycles of TDD</cite></a> », sur <span class="italique">The Clean Code Blog</span> <small style="line-height:1em;">(consulté le <time class="nowrap" datetime="2019-02-14" data-sort-value="2019-02-14">14 février 2019</time>)</small></span></span></span>

</li>

<li id="cite_note-:0-7"><span class="reference-text"><span class="ouvrage" id="Martin2009"><span class="ouvrage" id="Robert_C._Martin2009"><abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> Robert C. Martin, <cite class="italique" lang="en">Clean Code : A Handbook of Agile Software Craftsmanship</cite>, Upper Saddle River, NJ, <a href="Prentice_Hall" title="Prentice Hall">Prentice Hall</a>, <time>2009</time>, 431 <abbr class="abbr" title="pages">p.</abbr> <small style="line-height:1em;">(<a href="International_Standard_Book_Number" title="International Standard Book Number">ISBN</a> <span class="nowrap">978-0-13-235088-4</span>)</small>, Chapter 9: Unit Tests, The Three Laws of TDD, p. 122<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Clean+Code&rft.place=Upper+Saddle+River%2C+NJ&rft.pub=Prentice+Hall&rft.stitle=A+Handbook+of+Agile+Software+Craftsmanship&rft.aulast=Martin&rft.aufirst=Robert+C.&rft.date=2009&rft.pages=Chapter+9%3A+Unit+Tests%2C+The+Three+Laws+of+TDD%2C+p.+122&rft.tpages=431&rft.isbn=978-0-13-235088-4&rfr_id=info%3Asid%2Ffr.wikipedia.org%3ATest+driven+development"></span></span></span></span>

</li>

<li id="cite_note-rcmartin_blog-8"><span class="reference-text"><a rel="nofollow" class="external text" href="http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd">Robert C. Martin, The Three Laws of TDD, 2005</a></span>

</li>

<li id="cite_note-9"><span class="mw-cite-backlink"><a href="#cite_ref-9">↑</a> </span><span class="reference-text"><span class="ouvrage" id="MartinMartin2006"><span class="ouvrage" id="Robert_C._MartinMicah_Martin2006"><abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> Robert C. Martin et Micah Martin, <cite class="italique" lang="en">Agile Principles, Patterns, and Practices in C#</cite>, <a href="Prentice_Hall" title="Prentice Hall">Prentice Hall</a>, <time class="nowrap" datetime="2006-07-20" data-sort-value="2006-07-20">20 juillet 2006</time>, 768 <abbr class="abbr" title="pages">p.</abbr> <small style="line-height:1em;">(<a href="International_Standard_Book_Number" title="International Standard Book Number">ISBN</a> <span class="nowrap">0-13-185725-8</span>)</small>, Chapter 4. Testing, p. 32<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Agile+Principles%2C+Patterns%2C+and+Practices+in+C%23&rft.pub=Prentice+Hall&rft.aulast=Martin&rft.aufirst=Robert+C.&rft.au=Micah+Martin&rft.date=2006-07-20&rft.pages=Chapter+4.+Testing%2C+p.+32&rft.tpages=768&rft.isbn=0-13-185725-8&rfr_id=info%3Asid%2Ffr.wikipedia.org%3ATest+driven+development"></span></span></span></span>

</li>

<li id="cite_note-article_ieee_2007-10"><span class="mw-cite-backlink"><a href="#cite_ref-article_ieee_2007_10-0">↑</a> </span><span class="reference-text"><span class="ouvrage" id="Martin2007"><span class="ouvrage" id="Robert_C._Martin2007">Robert C. <span class="nom_auteur">Martin</span>, « <cite style="font-style:normal">Professionalism and Test-Driven Development</cite> », <i>IEEE Software</i>, <abbr class="abbr" title="volume">vol.</abbr> 24, <abbr class="abbr" title="numéro">n<sup>o</sup></abbr> 3,‎ <time class="nowrap" datetime="2007-05" data-sort-value="2007-05">mai 2007</time>, <abbr class="abbr" title="pages">p.</abbr> <span class="nowrap">32–36</span> <small style="line-height:1em;">(<a href="International_Standard_Serial_Number" title="International Standard Serial Number">ISSN</a> <span class=" noarchive"><a rel="nofollow" class="external text" href="https://portal.issn.org/resource/issn/0740-7459">0740-7459</a></span>, <a href="Digital_Object_Identifier" title="Digital Object Identifier">DOI</a> <span class=" noarchive nowrap"><a rel="nofollow" class="external text" href="https://dx.doi.org/10.1109/ms.2007.85">10.1109/ms.2007.85</a></span>, <a rel="nofollow" class="external text" href="https://dx.doi.org/10.1109/ms.2007.85">résumé</a>, <a rel="nofollow" class="external text" href="http://fpl.cs.depaul.edu/jriely/450/extras/prof-tdd.pdf">lire en ligne</a>, consulté le <time class="nowrap" datetime="2020-01-29" data-sort-value="2020-01-29">29 janvier 2020</time>)</small><span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.atitle=Professionalism+and+Test-Driven+Development&rft.jtitle=IEEE+Software&rft.issue=3&rft.aulast=Martin&rft.aufirst=Robert+C.&rft.date=2007-05&rft.volume=24&rft.pages=32%E2%80%9336&rft.issn=0740-7459&rft_id=info%3Adoi%2F10.1109%2Fms.2007.85&rfr_id=info%3Asid%2Ffr.wikipedia.org%3ATest+driven+development"></span></span></span></span>

</li>

<li id="cite_note-11"><span class="mw-cite-backlink"><a href="#cite_ref-11">↑</a> </span><span class="reference-text"><span class="ouvrage" id="Pigeon2020"><span class="ouvrage" id="Xavier_Pigeon2020"><abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> Xavier <span class="nom_auteur">Pigeon</span>, « <a rel="nofollow" class="external text" href="https://medium.com/@xavier.pigeon/du-test-first-design-au-test-driven-development-a07b05fdff6"><cite style="font-style:normal;" lang="en">Du Test First Design au Test-Driven Development</cite></a> », sur <span class="italique">Medium</span>, <time class="nowrap" datetime="2020-02-19" data-sort-value="2020-02-19">19 février 2020</time> <small style="line-height:1em;">(consulté le <time class="nowrap" datetime="2022-12-10" data-sort-value="2022-12-10">10 décembre 2022</time>)</small></span></span></span>

</li>

<li id="cite_note-12"><span class="mw-cite-backlink"><a href="#cite_ref-12">↑</a> </span><span class="reference-text"><span class="ouvrage" id="Beck2015"><span class="ouvrage" id="Kent_Beck2015">Kent <span class="nom_auteur">Beck</span>, <cite class="italique">Test-driven development: by example</cite>, Addison-Wesley, <abbr class="abbr" title="collection">coll.</abbr> « The Addison-Wesley signature series », <time>2015</time> <small style="line-height:1em;">(<a href="International_Standard_Book_Number" title="International Standard Book Number">ISBN</a> <span class="nowrap">978-0-321-14653-3</span>)</small><span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Test-driven+development%3A+by+example&rft.pub=Addison-Wesley&rft.aulast=Beck&rft.aufirst=Kent&rft.date=2015&rft.isbn=978-0-321-14653-3&rfr_id=info%3Asid%2Ffr.wikipedia.org%3ATest+driven+development"></span></span></span></span>

</li>

<li id="cite_note-13"><span class="mw-cite-backlink"><a href="#cite_ref-13">↑</a> </span><span class="reference-text"><span class="ouvrage"><abbr class="abbr indicateur-langue" title="Langue : anglais américain">(en-US)</abbr> « <a rel="nofollow" class="external text" href="https://petermorlion.com/how-does-tdd-help-with-technical-debt/"><cite style="font-style:normal;" lang="en-us">How Does TDD Help With Technical Debt? – Peter Morlion</cite></a> » <small style="line-height:1em;">(consulté le <time class="nowrap" datetime="2025-02-26" data-sort-value="2025-02-26">26 février 2025</time>)</small></span></span>

</li>

<li id="cite_note-14"><span class="mw-cite-backlink"><a href="#cite_ref-14">↑</a> </span><span class="reference-text"><span class="ouvrage" id="Varkholyak2018"><span class="ouvrage" id="Vasyl_Varkholyak2018"><abbr class="abbr indicateur-langue" title="Langue : anglais américain">(en-US)</abbr> Vasyl <span class="nom_auteur">Varkholyak</span>, « <a rel="nofollow" class="external text" href="https://lasoft.org/blog/test-driven-development-tdd/"><cite style="font-style:normal;" lang="en-us">What is Test Driven Development (TDD)? ⋆ Software Development Blog</cite></a> », sur <span class="italique">Software Development Blog</span>, <time class="nowrap" datetime="2018-07-30" data-sort-value="2018-07-30">30 juillet 2018</time> <small style="line-height:1em;">(consulté le <time class="nowrap" datetime="2025-02-26" data-sort-value="2025-02-26">26 février 2025</time>)</small></span></span></span>

</li>

<li id="cite_note-15"><span class="mw-cite-backlink"><a href="#cite_ref-15">↑</a> </span><span class="reference-text"><span class="ouvrage">« <a rel="nofollow" class="external text" href="https://fr.agilitest.com/cards/pair-programming"><cite style="font-style:normal;">Programmation en binôme | Agility Maturity Cards par Agilitest</cite></a> », sur <span class="italique">fr.agilitest.com</span> <small style="line-height:1em;">(consulté le <time class="nowrap" datetime="2025-02-26" data-sort-value="2025-02-26">26 février 2025</time>)</small></span></span>

</li>

</ol></div>

</div>

<div class="mw-heading mw-heading2"><h2 id="Voir_aussi">Voir aussi</h2></div>

/* start https://fr.wikipedia.org/ */

.mw-parser-output .autres-projets>.titre{text-align:center;margin:0.2em 0}.mw-parser-output .autres-projets>ul{margin:0;padding:0}.mw-parser-output .autres-projets>ul>li{list-style:none;margin:0.2em 0;text-indent:0;padding-left:24px;min-height:20px;text-align:left;display:block}.mw-parser-output .autres-projets>ul>li>a{font-style:italic}@media(max-width:720px){.mw-parser-output .autres-projets{float:none}}

/* end https://fr.wikipedia.org/ */

</style>

<div class="mw-heading mw-heading3"><h3 id="Articles_connexes">Articles connexes</h3></div>

<ul><li><a href="Cycle_de_d%C3%A9veloppement_(logiciel)" title="Cycle de développement (logiciel)">Cycle de développement</a></li>

<li><a href="Test_unitaire" title="Test unitaire">Test unitaire</a></li>

<li><i><span class="lang-en" lang="en"><a href="Extreme_programming" title="Extreme programming">Extreme programming</a></span></i></li>

<li><a href="R%C3%A9usinage_de_code" title="Réusinage de code">Réusinage de code</a></li>

<li><i><span class="lang-en" lang="en"><a href="Behavior-driven_development" class="mw-redirect" title="Behavior-driven development">Behavior-driven development</a></span></i></li></ul>

<div class="mw-heading mw-heading3"><h3 id="Bibliographie">Bibliographie</h3></div>

<ul><li><span class="ouvrage" id="Beck2002"><span class="ouvrage" id="Kent_Beck2002"><abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> Kent Beck, <cite class="italique" lang="en">Test Driven Development : By Example</cite>, <a href="Addison-Wesley" title="Addison-Wesley">Addison-Wesley</a>, <time>2002</time>, 240 <abbr class="abbr" title="pages">p.</abbr> <small style="line-height:1em;">(<a href="International_Standard_Book_Number" title="International Standard Book Number">ISBN</a> <span class="nowrap">0-321-14653-0</span>, <a rel="nofollow" class="external text" href="https://books.google.com/books?id=CUlsAQAAQBAJ&printsec=frontcover">lire en ligne</a>)</small><span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Test+Driven+Development&rft.pub=Addison-Wesley&rft.stitle=By+Example&rft.aulast=Beck&rft.aufirst=Kent&rft.date=2002&rft.tpages=240&rft.isbn=0-321-14653-0&rfr_id=info%3Asid%2Ffr.wikipedia.org%3ATest+driven+development"></span></span></span></li>

<li><span class="ouvrage" id="Koskela2007"><span class="ouvrage" id="Lasse_Koskela2007"><abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> Lasse Koskela, <cite class="italique" lang="en">Test Driven : TDD and Acceptance TDD for Java Developers</cite>, Manning, <time>2007</time>, 470 <abbr class="abbr" title="pages">p.</abbr> <small style="line-height:1em;">(<a href="International_Standard_Book_Number" title="International Standard Book Number">ISBN</a> <span class="nowrap">978-1-932394-85-6</span> et <span class="nowrap">1-932394-85-0</span>)</small><span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Test+Driven+%3A+TDD+and+Acceptance+TDD+for+Java+Developers&rft.pub=Manning&rft.aulast=Koskela&rft.aufirst=Lasse&rft.date=2007&rft.tpages=470&rft.isbn=978-1-932394-85-6&rfr_id=info%3Asid%2Ffr.wikipedia.org%3ATest+driven+development"></span></span></span></li></ul>

<div class="mw-heading mw-heading3"><h3 id="Liens_externes">Liens externes</h3></div>

<ul><li><a rel="nofollow" class="external text" href="http://www.c2.com/cgi/wiki?TestDrivenProgramming">TestDrivenProgramming</a></li>

<li><a rel="nofollow" class="external text" href="https://medium.com/@xavier.pigeon/du-test-first-design-au-test-driven-development-a07b05fdff6">Du Test First Design au Test-Driven Development</a>, Xavier Pigeon</li>

<li><a rel="nofollow" class="external text" href="https://gearsoftesting.org/tempo-of-testing.html">Tempo of Testing (GOST)</a>, Xavier Pigeon</li>

<li>Didacticiels

<ul><li><a rel="nofollow" class="external text" href="http://despeludo.developpez.com/articles/testsunitaires/">Tutoriel (VS2008 et C#) de Ludovic Stumme sur Developpez.com (HTML)</a></li>

<li><a rel="nofollow" class="external text" href="http://bruno-orsier.developpez.com/tutoriels/TDD/pentaminos/">Tutoriel (pentaminos) de Bruno Orsier sur Developpez.com (HTML)</a></li>

<li><a rel="nofollow" class="external text" href="http://dboissier.developpez.com/tutoriels/test-driven-development">Tutoriel (orienté Java) de David Boissier sur Developpez.com (PDF/HTML)</a></li>

<li><a rel="nofollow" class="external text" href="http://jp-grossglauser.developpez.com/tutoriels/langages/php/phpunit/">Tutoriel (PHPUnit) de Jean-Pierre Grossglauser sur Developpez.com (PDF/HTML)</a></li></ul></li></ul>

<ul id="bandeau-portail" class="bandeau-portail"><li><span class="bandeau-portail-element"><span class="bandeau-portail-icone"><span class="noviewer" typeof="mw:File"></span></span> <span class="bandeau-portail-texte">Portail de la programmation informatique</span> </span></li> </ul></div><div><div class="zim-footer">

Cet article est issu de <a class="external text" title="Dernière modification le 2025-04-10" href="https://fr.wikipedia.org/wiki/?title=Test_driven_development&oldid=224692157">Wikipédia</a>. Sauf mention contraire, le texte est disponible sous <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.fr">Creative Commons Attribution-Share Alike 4.0</a>. Des conditions supplémentaires peuvent s’appliquer aux fichiers multimédias.

</div>

</div></div>

</div>

</main>

</div>

</body></html>